9. 네트워크 종류와 구성 3
34. SDN: 네트워크 관리 기능을 집약하는 기술
SDN의 탄생 배경
전통적 네트워크의 한계:
전통적 네트워크 관리의 한계:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[관리자]
│
┌───────┬───────┼───────┬───────┐
│ │ │ │ │
↓ ↓ ↓ ↓ ↓
[스위치 1] [스위치 2] [스위치 3] [라우터 1] [라우터 2]
개별 설정 개별 설정 개별 설정 개별 설정 개별 설정
각 장비마다 CLI로 접속하여 개별 설정 필요
문제점:
├─ 장비별 개별 설정: CLI 접속 필요
├─ 설정 불일치: 휴먼 에러 발생
├─ 변경 어려움: 확장성 부족
└─ 자동화 한계: 수동 작업 불가피
VLAN의 한계:
VLAN은 논리적 세그먼트 구성에 유용하지만:
❌ 여전히 개별 스위치 설정 필요
❌ 태그와 레이블만으로 부족한 경우 존재
❌ 대규모 네트워크에서 관리 복잡성 증가
❌ 동적 변경 어려움
→ SDN으로 해결
SDN의 핵심 개념
SDN (Software-Defined Networking): 네트워크 설계와 구성을 소프트웨어 기반으로 가상화하여 중앙 집중식으로 관리
SDN 아키텍처:
┌─────────────────────────────────────────────────────┐
│ 컨트롤 플레인 (Control Plane) │
│ │
│ [SDN 컨트롤러] │
│ (중앙 관리) │
│ │
└─────────┬──────────┬──────────┬──────────┬─────────┘
│(제어) │(제어) │(제어) │(제어)
↓ ↓ ↓ ↓
┌─────────────────────────────────────────────────────┐
│ 데이터 플레인 (Data Plane) │
│ │
│ [SDN 스위치 1] ← → [SDN 스위치 2] │
│ 패킷 전달만 패킷 전달만 │
│ │
│ ↕ ↕ ↕ │
│ │
│ [SDN 스위치 3] ← → [SDN 스위치 4] │
│ 패킷 전달만 패킷 전달만 │
│ │
└─────────────────────────────────────────────────────┘
핵심 원리:
├─ 제어와 전달 분리: Control Plane / Data Plane
├─ 중앙 집중 관리: SDN 컨트롤러
└─ 프로그래밍 가능: 소프트웨어 정의
컨트롤 플레인과 데이터 플레인 분리
전통적 네트워크 (Control + Data 통합):
전통적 스위치/라우터 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌─────────────────────────────────┐
│ 전통적 스위치/라우터 (통합) │
│ │
│ [컨트롤 플레인] │
│ 라우팅 결정 │
│ 설정 관리 │
│ ↓ │
│ [데이터 플레인] │
│ 패킷 전달 │
│ 하드웨어 처리 │
│ │
└─────────────────────────────────┘
특징:
├─ 자율적 동작: 독립 장비
├─ 개별 설정 필요
└─ 분산 지능
SDN 네트워크 (Control과 Data 분리):
SDN 네트워크 구조 (분리):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[컨트롤 플레인]
(중앙 집중)
│
┌───────────┼───────────┐
│ OpenFlow/ │ OpenFlow/ │ OpenFlow/
│ NETCONF │ NETCONF │ NETCONF
↓ ↓ ↓
┌─────────────────────────────────┐
│ 데이터 플레인 │
│ │
│ [스위치 1] [스위치 2] [스위치 3] │
│ 패킷 전달 패킷 전달 패킷 전달 │
│ │
└─────────────────────────────────┘
특징:
├─ 집중 지능: 컨트롤러에 집중
├─ 단순 스위치: 명령 수행만
└─ 중앙 관리: 통합 제어
SDN 아키텍처와 계층
SDN 3계층 구조:
┌─────────────────────────────────────────────────────┐
│ 애플리케이션 계층 (Application Layer) │
│ │
│ [네트워크 앱 1] [네트워크 앱 2] [네트워크 앱 3] │
│ 방화벽 로드밸런서 모니터링 │
│ │
└─────────────┬───────────┬───────────┬───────────────┘
│ │ │
└───────────┼───────────┘
↓
[ Northbound API: REST API ]
(앱 ↔ 컨트롤러 통신)
↓
┌─────────────────────────────────────────────────────┐
│ 컨트롤 계층 (Control Layer) │
│ │
│ [SDN 컨트롤러] │
│ (네트워크 OS) │
│ │
└─────────────────────────┬───────────────────────────┘
↓
[ Southbound API: OpenFlow, NETCONF ]
(컨트롤러 ↔ 스위치 통신)
│
┌───────────┼───────────┐
↓ ↓ ↓
┌─────────────────────────────────────────────────────┐
│ 인프라 계층 (Infrastructure Layer) │
│ │
│ [SDN 스위치 1] [SDN 스위치 2] [SDN 스위치 3] │
│ │
└─────────────────────────────────────────────────────┘
API 역할:
├─ Northbound API: 애플리케이션 ↔ 컨트롤러 통신
└─ Southbound API: 컨트롤러 ↔ 스위치 통신
SDN 프로토콜과 API
OpenFlow:
OpenFlow 프로토콜 동작:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[호스트] [OpenFlow 스위치] [SDN 컨트롤러]
│ │ │
│ 1. 패킷 도착 │ │
│ (처음 보는 플로우) │ │
├──────────────────→│ │
│ │ │
│ │ 플로우 테이블에 │
│ │ 매칭 없음 │
│ │ │
│ │ 2. Packet-In │
│ │ "이 패킷 어떻게 처리?" │
│ ├───────────────────────→│
│ │ │
│ │ │ 정책 결정
│ │ │ 경로 계산
│ │ │
│ │ 3. Flow-Mod │
│ │ "이렇게 처리해" │
│ │ 플로우 규칙 설치 │
│ │←───────────────────────┤
│ │ │
│ │ 플로우 테이블 │
│ │ 업데이트 │
│ │ │
│ 4. 패킷 전달 │ │
│←──────────────────┤ │
│ │ │
│ │ 이후 같은 플로우는 │
│ │ 자동 처리 │
│ │ │
OpenFlow 플로우 테이블:
플로우 테이블 구조:
┌──────────────────────────────────────────────┐
│ Match Fields (매칭 조건) │
│ - 출발지 IP, 목적지 IP │
│ - 출발지 포트, 목적지 포트 │
│ - 프로토콜 (TCP/UDP) │
│ - VLAN ID, MAC 주소 등 │
├──────────────────────────────────────────────┤
│ Priority (우선순위) │
├──────────────────────────────────────────────┤
│ Counters (통계) │
│ - 패킷 수, 바이트 수 │
├──────────────────────────────────────────────┤
│ Instructions (실행 명령) │
│ - Forward (특정 포트로 전달) │
│ - Drop (폐기) │
│ - Modify (헤더 변경) │
│ - Send to Controller │
└──────────────────────────────────────────────┘
예시 플로우 엔트리:
출발지: 10.0.1.5, 목적지: 10.0.2.10, 프로토콜: TCP
→ 액션: 포트 3으로 전달
NETCONF:
NETCONF (Network Configuration Protocol):
- XML 기반 설정 프로토콜
- 장비 설정/상태 조회
- 트랜잭션 지원
- 설정 롤백 가능
사용 예:
<rpc>
<edit-config>
<target><running/></target>
<config>
<interfaces>
<interface>
<name>eth0</name>
<ipv4>10.0.1.1/24</ipv4>
</interface>
</interfaces>
</config>
</edit-config>
</rpc>
REST API (Northbound):
애플리케이션이 컨트롤러를 제어하는 API
HTTP 기반:
GET /networks/{id} → 네트워크 정보 조회
POST /networks → 새 네트워크 생성
PUT /networks/{id} → 네트워크 수정
DELETE /networks/{id} → 네트워크 삭제
예시 (JSON):
POST /networks
{
"name": "production",
"subnet": "10.0.1.0/24",
"gateway": "10.0.1.1",
"vlan": 10
}
→ 웹 브라우저나 스크립트로 네트워크 관리 가능
SDN의 실무 활용
클라우드 서비스 제공자 (CSP):
클라우드 서비스 제공자의 SDN 활용:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌─────────────────────────┐
│ SDN 컨트롤러 │
│ (중앙 관리 플랫폼) │
└──────────┬──────────────┘
│ SDN 제어
┌───────────┼───────────┐
│ │ │
↓ ↓ ↓
┌──────────────────────────────────────────┐
│ 물리적 네트워크 │
│ │
│ [데이터센터 1] [데이터센터 2] [데이터센터 3] │
│ 서울 부산 제주 │
│ │
└──────────────────────────────────────────┘
↑ ↑ ↑
│논리적 │논리적 │논리적
│네트워크 │네트워크 │네트워크
│ │ │
┌──────────────────────────────────────────┐
│ 가상 네트워크 │
│ │
│ [고객 A VPC] [고객 B VPC] [고객 C VPC] │
│ 10.0.0.0/16 172.16.0.0/16 192.168.0.0/16 │
│ │
└──────────────────────────────────────────┘
SDN 활용:
├─ 가상 네트워크 동적 생성
├─ 물리적 위치 무관
└─ 고객별 격리 (멀티 테넌시)
통신 사업자:
SDN 활용 사례:
━━━━━━━━━━━━━━━━━━━━━━━
1. 네트워크 슬라이싱 (5G)
- 용도별 가상 네트워크 분리
- eMBB (초고속), URLLC (초저지연), mMTC (대규모 IoT)
2. 트래픽 엔지니어링
- 실시간 트래픽 분석
- 동적 경로 최적화
- 혼잡 회피
3. 서비스 체이닝
- 방화벽 → IPS → 로드밸런서
- 소프트웨어로 순서 정의
가상 서버 관리:
SDN을 활용한 가상 서버 생성 시 네트워크가 자동으로 구성됩니다:
- 사용자가 클라우드 포털에서 VM 생성 요청
- 포털이 SDN 컨트롤러에 네트워크 설정 요청
- SDN 컨트롤러가 네트워크 구성 계산 (VLAN, 라우팅 경로)
- OpenFlow 명령으로 플로우 규칙을 물리 스위치에 배포
- 스위치 설정 완료, 가상 네트워크 생성
- 사용자에게 VM 접속 정보 제공
결과: 몇 분 만에 복잡한 네트워크 자동 구성
SDN의 장단점
장점:
[SDN 주요 장점]
├─ 중앙 집중 관리
│ → 단일 지점에서 제어
│
├─ 자동화
│ → API 기반 관리
│
├─ 유연성
│ → 빠른 변경
│
├─ 가상화
│ → 논리적 네트워크
│
├─ 프로그래밍 가능
│ → 맞춤형 정책
│
└─ 비용 절감
→ 범용 하드웨어 사용
[실무 효과]
├─ 배포 시간 단축: 몇 주 → 몇 분
├─ 운영 비용 감소: 자동화
└─ 민첩성 향상: DevOps 친화
단점:
[SDN 주요 단점]
├─ 컨트롤러 의존
│ → 단일 장애점 (SPOF)
│
├─ 초기 투자
│ → SDN 장비 교체 비용
│
├─ 복잡성
│ → 새로운 기술 스택
│
├─ 표준화 부족
│ → 벤더 종속 위험
│
└─ 성능 오버헤드
→ 컨트롤러 통신 지연
[완화 방안]
├─ 컨트롤러 이중화: 고가용성 확보
├─ 점진적 도입: 하이브리드 구성
└─ 교육 투자: 전문 인력 양성
전통 네트워크 vs SDN 비교
| 구분 | 전통 네트워크 | SDN |
|---|---|---|
| 제어 방식 | 분산 (각 장비) | 중앙 집중 (컨트롤러) |
| 설정 방법 | CLI, 개별 접속 | API, 프로그래밍 |
| 변경 속도 | 느림 (수동) | 빠름 (자동) |
| 가상화 | 제한적 (VLAN) | 완전 (논리 네트워크) |
| 확장성 | 어려움 | 용이 |
| 자동화 | 제한적 | 완전 |
| 비용 | 고가 장비 | 범용 장비 |
| 복잡성 | 익숙함 | 새로운 학습 필요 |
핵심 이해
SDN의 본질:
━━━━━━━━━━━━━━━━━━━━━━━
네트워크를 "소프트웨어"로 정의
전통 방식:
하드웨어 중심 → 물리적 배선/설정
SDN 방식:
소프트웨어 중심 → 논리적 정의/제어
비유:
━━━━━━━━━━━━━━━━━━━━━━━
전통 네트워크 = 수동 변속기
→ 기어마다 직접 조작
SDN = 자동 변속기 + 크루즈 컨트롤
→ 목표만 입력하면 자동 제어
효과:
✅ 물리적 제약에서 자유로움
✅ 코드로 네트워크 관리
✅ 클라우드 시대의 필수 기술
✅ DevOps/IaC와 통합 가능
35. LAN끼리 연결한 네트워크
세그먼트 통합의 필요성
다중 세그먼트 환경:
┌────────────────────────┐
│ 건물 3층 │
│ │
│ [세그먼트 C] │
│ 192.168.3.0/24 │
└────────────────────────┘
┌────────────────────────┐
│ 건물 2층 │
│ │
│ [세그먼트 B] │
│ 192.168.2.0/24 │
└────────────────────────┘
┌────────────────────────┐
│ 건물 1층 │
│ │
│ [세그먼트 A] │
│ 192.168.1.0/24 │
└────────────────────────┘
상위 통합 필요:
├─ 세그먼트 간 통신
├─ 인터넷 공유
└─ 서버 공동 사용
스위치를 이용한 세그먼트 통합
L2 스위치 계층 구조:
┌─────────────────────────────┐
│ 상위 세그먼트 │
│ │
│ [코어 스위치] │
│ (L2 집선) │
│ │
└─────┬─────────┬─────────┬───┘
│ │ │
↕ ↕ ↕
┌─────────────────────────────┐
│ 하위 세그먼트들 │
│ │
│ [플로어 [플로어 [플로어 │
│ 스위치 1] 스위치 2] 스위치 3]│
│ 1층 2층 3층 │
│ │
└─────────────────────────────┘
특징:
├─ 2계층 확장: MAC 기반
├─ 브로드캐스트 도메인 확대
└─ 스패닝 트리: 루프 방지
L2만으로는 부족한 이유:
문제점:
❌ 브로드캐스트 도메인 과대
→ 모든 플로어에 브로드캐스트 전파
→ 네트워크 성능 저하
❌ MAC 테이블 부담
→ 수천~수만 개 MAC 주소 관리
→ 스위치 메모리/성능 한계
❌ 보안 문제
→ 물리적 분리 없음
→ 부서 간 격리 어려움
해결책: L3 장비 도입
라우터/L3 스위치를 이용한 세그먼트 통합
L3 기반 계층 구조:
[인터넷]
↕
[경계 라우터/게이트웨이]
↕
[코어 L3 스위치]
(라우팅 + 스위칭)
│
┌──────────┼──────────┐
│ │ │
↕ ↕ ↕
┌──────────────────────────────────┐
│ 부서별 세그먼트 │
│ │
│ [개발팀] [영업팀] [재무팀] │
│ 10.0.10.0/24 10.0.20.0/24 10.0.30.0/24 │
│ VLAN 10 VLAN 20 VLAN 30 │
│ │
└──────────────────────────────────┘
L3 장비의 효과:
├─ 서브넷 분리: IP 기반 관리
├─ 브로드캐스트 격리
├─ 라우팅: 세그먼트 간 통신 지원
└─ 정책 적용: ACL/방화벽
트래픽 양과 장치 수에 따른 선택
소규모 네트워크:
[L2 스위치]
│
┌──────┴──────┐
│ │
[PC 10대] [프린터 2대]
특징:
├─ 단일 세그먼트 (~50대)
├─ 저렴한 비용
└─ 간단한 관리
중규모 네트워크:
[코어 L3 스위치]
(라우팅 기능)
│
┌───────┼───────┐
│ │ │
↕ ↕ ↕
┌───────────────────────────┐
│ 부서별 L2 스위치 │
│ │
│ [1층 스위치] [2층 스위치] [3층 스위치] │
│ 50대 40대 60대 │
│ │
└───────────────────────────┘
특징:
├─ 다중 세그먼트 (50~500대)
├─ VLAN 활용
└─ 부서별 격리
대규모 네트워크:
[코어 라우터]
(BGP 지원)
│
┌────────┼────────┐
│ │ │
↕ ↕ ↕
┌──────────────────────────────┐
│ 분산 L3 스위치 │
│ │
│ [빌딩 A] [빌딩 B] [빌딩 C] │
│ L3 스위치 L3 스위치 L3 스위치 │
│ │ │ │ │
└─────┼────────┼────────┼───────┘
│ │ │
↓ ↓ ↓
┌──────────────────────────────┐
│ 각 빌딩 내부 │
│ │
│ 플로어별 L2 스위치 │
│ │
└──────────────────────────────┘
특징:
├─ 수천~수만 대
├─ 계층적 설계
└─ 고성능 코어
서버 세그먼트의 분리
서버 전용 세그먼트 필요성:
[L3 코어 스위치]
│
┌─────┬─────┼─────┬─────┐
│ │ │ │ │
↕ ↕ ↕ ↕ ↕
┌──────────────────────────────────────┐
│ 사용자 세그먼트 │
│ │
│ [개발팀] [영업팀] [재무팀] │
│ 10.0.10.0/24 10.0.20.0/24 10.0.30.0/24 │
│ │
└──────────────────────────────────────┘
┌──────────────────────────────────────┐
│ 서버 세그먼트 │
│ │
│ [서버 팜] │
│ 10.0.100.0/24 │
│ (독립 VLAN) │
│ │
└──────────────────────────────────────┘
서버 분리 이유:
├─ 공유 리소스: 모든 부서 접근
├─ 보안 강화: 방화벽 정책 적용
├─ 성능 보장: 전용 대역폭
└─ 관리 편의: 집중 모니터링
서버 세그먼트 접근 제어:
개발팀 PC가 웹 서버에 접속할 때, 방화벽/ACL이 출발지, 목적지, 포트를 검사하여 허용된 트래픽만 통과시킵니다. SSH (22번 포트)는 ACL로 차단 가능합니다.
서버 세그먼트 설계 예시:
서버 세그먼트 구성:
━━━━━━━━━━━━━━━━━━━━━━━
10.0.100.0/24 - 웹 서버 (DMZ)
10.0.101.0/24 - 애플리케이션 서버
10.0.102.0/24 - 데이터베이스 서버
10.0.110.0/24 - 백업 서버
10.0.120.0/24 - 관리 서버
접근 정책:
━━━━━━━━━━━━━━━━━━━━━━━
인터넷 → 웹 서버 (80, 443만 허용)
사용자 → 앱 서버 (제한적 접근)
앱 서버 → DB 서버 (3306, 5432만)
관리자 → 관리 서버 (SSH, RDP)
물리 계층과 데이터 링크 계층의 추상화
L3 장비의 추상화 효과:
[L3 스위치/라우터]
│
↓
[IP 주소 기반 논리적 관리]
│
┌────┴────┐
│ │
↓ ↓
[물리 계층 숨김] [데이터 링크 계층 숨김]
케이블 종류 무관 MAC 주소 내부 처리
[관리자 관점]
├─ IP 주소와 서브넷만 관리
├─ 물리적 배선 신경 안 씀
└─ 유연한 재구성
[실무 예시]
├─ 10.0.10.0/24 → 개발팀
├─ 물리적으로는: 여러 스위치에 분산
└─ 논리적으로는: 하나의 세그먼트
추상화의 이점:
추상화 계층:
━━━━━━━━━━━━━━━━━━━━━━━
L3 (IP) - 관리자가 주로 다루는 계층
↑ 추상화
L2 (MAC) - 스위치가 자동 처리
↑ 추상화
L1 (물리) - 하드웨어가 자동 처리
효과:
✅ 복잡성 감소
✅ 유연한 네트워크 설계
✅ 물리적 변경에 강함
✅ 확장 용이
핵심 이해
LAN 통합의 진화:
━━━━━━━━━━━━━━━━━━━━━━━
1단계: L2 스위치로 물리적 확장
→ MAC 주소 기반
→ 단일 브로드캐스트 도메인
→ 소규모 적합
2단계: VLAN으로 논리적 분할
→ 같은 스위치 내 세그먼트 분리
→ 브로드캐스트 격리
→ 중규모 적합
3단계: L3 장비로 세그먼트 간 라우팅
→ IP 기반 관리
→ 부서별 독립 세그먼트
→ 서버 분리 가능
→ 대규모 적합
핵심 원칙:
━━━━━━━━━━━━━━━━━━━━━━━
"트래픽 양과 장치 수에 따라
적절한 계층의 장비 선택"
서버는 항상 독립 세그먼트!